---
title: Service Account permissions
---

This is an explanation of the [kubernetes permissions](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 
used by the Weave GitOps service account. This is the service account used by
the application itself (rather than the static user used for demo/emergency
access, the permissions for which are covered in the [static user permissions](user-permissions.mdx)
page)

The default permissions of the service account are defined in the [helm chart](https://github.com/weaveworks/weave-gitops/tree/main/charts/gitops-server/templates/role.yaml) which
will generate a cluster role with the following permissions:

```yaml
rules:
# Used to query the cluster
- apiGroups: [""]
  resources:  ["users", "groups"]  # set by rbac.impersonationResources
  verbs: [ "impersonate" ]
  # resourceNames: []              # set by rbac.impersonationResourceNames
# Used to get OIDC/static user credentials for login
- apiGroups: [""]
  resources: [ "secrets" ]
  verbs: [ "get", "list" ]
  resourceNames:                  # set by rbac.viewSecretsResourceNames
    - "cluster-user-auth"
    - "oidc-auth"
# The service account needs to read namespaces to know where it can query
- apiGroups: [ "" ]
  resources: [ "namespaces" ]
  verbs: [ "get", "list" ]
```

These allow the pod to do three things:
* [impersonate](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) the user and operate in cluster as them
* read the available namespaces (this is required to understand the users' permissions)
* read the `cluster-user-auth` and `oidc-auth` secrets, which are the default secrets
  to store the cluster-user account and OIDC configuration (see
  [securing access to the dashboard](securing-access-to-the-dashboard.mdx))

## The Helm values

| Value                             | Description                                                         | Default                              |
|-----------------------------------|---------------------------------------------------------------------|--------------------------------------|
| `rbac.impersonationResources`     | Which resource types the service account can impersonate            | `["users", "groups"]`                |
| `rbac.impersonationResourceNames` | Specific users, groups or services account that can be impersonated | `[]`                                 |
| `rbac.viewSecretsResourceNames`   | Specific secrets that can be read                                   | `["cluster-user-auth", "oidc-auth"]` |


## Impersonation

The primary way Weave GitOps queries the Kube API is via `impersonation`, the
application (not the cluster) authenticates the user (either via the static
cluster-user credentials or OIDC) then makes calls to the Kube API on the user's
behalf. This is equivalent to making a kubectl call like:

```bash
$ kubectl get deployments --as aisha@example.com
```

Assuming the user `aisha@example.com` has been granted permissions to get
deployments within the cluster then this will return them. The same occurs 
within the application. This makes the proper configuration of the application's
permissions very important as, without proper restrictions it can impersonate
very powerful `users` or `groups`. For example, the `system:masters` is group
is generally bound to the `cluster-admin` role which can do anything.

For more details of the permissions needed by the user or group see the
[user permissions](user-permissions.mdx) guide.

### Configuring impersonation

It is highly recommended that you limit which users and groups that the
application can impersonate by setting `rbac.impersonationResourceNames` in
the Helm chart's `values`. e.g.:

```yaml
rbac:
  impersonationResources: ["groups"]
  impersonationResourceNames:
    - admin
    - dev-team
    - qa-team
```
In this example the application can only impersonate the groups admin, dev-team
and qa-team (this also, implicitly disables the static cluster-user).

Unfortunately not all OIDC providers support groups so you may need to
manually enumerate users, for example:
```yaml
rbac:
  impersonationResources: ["users"]
  impersonationResourceNames:
    - aisha@example.com
    - bill@example.com
    - wego-admin         # enable the static cluster-user
```

A better, albeit more involved, solution is to set up an OIDC connector like 
[Dex](../guides/setting-up-dex.md) and use that to manage groups for you.

## Get namespaces

The application itself uses get namespace permissions to pre-cache the list of
available namespaces. As the user accesses resources their permissions within
various namespaces is also cached to speed up future operations.

## Reading the cluster-user-auth and oidc-auth secrets

The cluster-user-auth and oidc-auth secrets provide information for authenticating
to the application. The former holds the username and bcrypt-hashed password
for the static user and the later holds OIDC configuration.

The application needs to be able to access these secrets in order to
authenticate users.

### Configuring secrets

The `rbac.viewSecretsResourceNames` value allows the operator to change which secrets the
application can read. This is mostly so that, if the static user is not
configured, that secret can be removed; or if the secret to be used is re-named.
